javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java (1)

1696-1699: ⚠️ Potential issue | 🔴 Critical

Guard argument access in getIdxForGetCall to avoid crash.

Line 1698 dereferences argument index 0 unconditionally. A zero-arg get() call will throw IndexOutOfBoundsException.

🐛 Proposed fix

 public static `@Nullable` ExpressionTree getIdxForGetCall(Tree tree) {
-  if ((tree instanceof MethodInvocationTree mit) && isNamedMethodCall("get", mit)) {
+  if ((tree instanceof MethodInvocationTree mit)
+      && isNamedMethodCall("get", mit)
+      && !mit.getArguments().isEmpty()) {
     return mit.getArguments().get(0);
   }
   return null;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java` around
lines 1696 - 1699, getIdxForGetCall currently assumes the MethodInvocationTree
mit has at least one argument and calls mit.getArguments().get(0), which can
throw IndexOutOfBoundsException for zero-arg get() calls; update
getIdxForGetCall to first check the argument list (e.g.,
mit.getArguments().isEmpty() or size() > 0) before accessing index 0 and return
null when there are no arguments so zero-arg calls are safely handled.

checker/src/main/java/org/checkerframework/checker/mustcall/MustCallAnnotatedTypeFactory.java (1)

177-221: ⚠️ Potential issue | 🟠 Major

Always recurse into nested declared type arguments.

replaceCollectionTypeVarsWithBottomIfTop still only descends into AnnotatedDeclaredType arguments when the outer type is a collection. That means wrappers like Optional<List<?>> or Holder<Iterator<?>> still skip the inner collection/iterator and leave its element type at @MustCallUnknown.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/mustcall/MustCallAnnotatedTypeFactory.java`
around lines 177 - 221, The current logic only enters the loop that calls
replaceCollectionTypeVarsWithBottomIfTop when
ResourceLeakUtils.isCollection(adt.getUnderlyingType()), so nested declared type
arguments inside non-collection wrappers (e.g., Optional<List<?>>) are never
traversed; update the traversal so that for any AnnotatedDeclaredType you always
recurse into its type arguments and call
replaceCollectionTypeVarsWithBottomIfTop on each declared type argument (use the
existing method replaceCollectionTypeVarsWithBottomIfTop and the same handling
used for typeArg.getKind() == TypeKind.DECLARED), not just when the outer adt is
a collection, ensuring inner collections/iterators have their element types
reset from `@MustCallUnknown` to `@MustCallBottom` when appropriate.

framework/src/main/java/org/checkerframework/framework/type/GenericAnnotatedTypeFactory.java (1)

1199-1214: ⚠️ Potential issue | 🟠 Major

Handle missing block input in getRegularStore.

flowResult.getInput(block) / analysis.getInput(block) can be absent for unreachable or unanalyzed blocks. This dereferences input unconditionally, so callers get an NPE instead of the nullable behavior used by the neighboring store accessors.

Suggested fix

-  public Store getRegularStore(Block block) {
+  public `@Nullable` Store getRegularStore(Block block) {
     TransferInput<Value, Store> input;
     if (!analysis.isRunning()) {
       input = flowResult.getInput(block);
     } else {
       input = analysis.getInput(block);
     }
-
-    return input.getRegularStore();
+    if (input == null) {
+      return null;
+    }
+    return input.getRegularStore();
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@framework/src/main/java/org/checkerframework/framework/type/GenericAnnotatedTypeFactory.java`
around lines 1199 - 1214, The getRegularStore method dereferences the
TransferInput from flowResult.getInput(block) or analysis.getInput(block)
without null-check, causing NPE for unreachable/unanalyzed blocks; update
getRegularStore to check whether the selected TransferInput is null and return
null (matching neighboring store accessors' nullable behavior) when absent
instead of calling input.getRegularStore(), using the same selection logic
around analysis.isRunning(), and reference the symbols getRegularStore,
flowResult.getInput, analysis.getInput, and TransferInput in your change.

checker/src/main/java/org/checkerframework/checker/collectionownership/IndexedForDisposalLoopMatcher.java (1)

143-149: ⚠️ Potential issue | 🟠 Major

Use value equality for Name comparisons.

These Name checks rely on reference equality. That can silently miss valid matches or accept the wrong symbol when the compiler implementation does not reuse the same Name instance. Use .equals(...) / Objects.equals(...) throughout this matcher.

Based on learnings: In MustCallVisitor.java (Checker Framework), prefer using Name.equals(...) or Objects.equals(...) for com.sun.source.util.Name comparisons instead of ==/!=.

Also applies to: 190-225, 252-255

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/IndexedForDisposalLoopMatcher.java`
around lines 143 - 149, The code in IndexedForDisposalLoopMatcher uses reference
equality (== / !=) for com.sun.source.util.Name comparisons which is unsafe;
replace these with value equality using .equals(...) or Objects.equals(...) for
initVarName vs ((IdentifierTree) condition.getLeftOperand()).getName() and
initVarName vs ((IdentifierTree) inc.getExpression()).getName(), and update the
other similar checks in this class (the other Name comparisons around the later
matching logic) to use .equals/Objects.equals so name comparisons are by value
rather than reference.

checker/src/main/java/org/checkerframework/checker/rlccalledmethods/RLCCalledMethodsAnnotatedTypeFactory.java (1)

183-191: ⚠️ Potential issue | 🟠 Major

Lambda disposal loops still never reach discovery.

GenericAnnotatedTypeFactory.postCFGConstruction(...) is invoked for lambda CFGs too, but this guard only records disposal loops for METHOD. That means a disposal loop inside a lambda is never available to RLCCalledMethodsTransfer.initialStore(...), so collection obligations inside lambdas cannot be discharged through this path.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/rlccalledmethods/RLCCalledMethodsAnnotatedTypeFactory.java`
around lines 183 - 191, The postCFGConstruction method only calls
ResourceLeakUtils.getCollectionOwnershipAnnotatedTypeFactory(this).discoverDisposalLoops(cfg)
when ast.getKind() == UnderlyingAST.Kind.METHOD, which skips lambda CFGs; update
the guard so disposal-loop discovery also runs for lambda CFGs (e.g.,
ast.getKind() == UnderlyingAST.Kind.METHOD || ast.getKind() ==
UnderlyingAST.Kind.LAMBDA) or remove the kind check entirely so
discoverDisposalLoops(cfg) runs for lambda CFGs as well, ensuring
RLCCalledMethodsTransfer.initialStore(...) sees disposal loops inside lambdas.

checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipTransfer.java (2)

313-313: 🧹 Nitpick | 🔵 Trivial

Prefer isEmpty() over size() == 0 for clarity.

Suggested improvement

-      boolean isDiamond = node.getTree().getTypeArguments().size() == 0;
+      boolean isDiamond = node.getTree().getTypeArguments().isEmpty();

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipTransfer.java`
at line 313, The expression checking for an empty type-arguments list uses
size() == 0 which is less clear; replace the check in
CollectionOwnershipTransfer where isDiamond is assigned (currently using
node.getTree().getTypeArguments().size() == 0) with the clearer isEmpty() call
on the type arguments collection (e.g.,
node.getTree().getTypeArguments().isEmpty()) so isDiamond uses isEmpty() instead
of size() == 0.

---

253-282: ⚠️ Potential issue | 🟠 Major

Guard nullable argElem before calling getKind().

TreeUtils.elementFromTree(arg.getTree()) can return null for temp vars, method results, and other non-element trees. Line 276 calls argElem.getKind() without checking for null, which will throw NullPointerException.

Proposed fix

       if (transferOwnership) {
-        if (argElem.getKind().isField()) {
+        if (argElem != null && argElem.getKind().isField()) {
           checker.reportError(
               arg.getTree(), "transfer.owningcollection.field.ownership", arg.getTree().toString());
         } else {
           replaceInStores(res, argJE, atypeFactory.NOTOWNINGCOLLECTION);
         }
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipTransfer.java`
around lines 253 - 282, Guard against a null Element returned by
TreeUtils.elementFromTree(arg.getTree()) before calling getKind(): in
CollectionOwnershipTransfer (around the block using argElem, transferOwnership,
and the calls to checker.reportError and replaceInStores) add a null-check so
that if argElem is null it is treated as "not a field" (i.e., call
replaceInStores(res, argJE, atypeFactory.NOTOWNINGCOLLECTION)) and only call
argElem.getKind().isField() when argElem != null; update the conditional that
currently does if (argElem.getKind().isField()) ... else ... to first test
argElem != null.

framework/src/main/java/org/checkerframework/framework/flow/CFAbstractStore.java (2)

79-80: ⚠️ Potential issue | 🟠 Major

Evict iterated-element facts after mutations.

The iteratedCollectionElements map is not cleared in mutation/invalidation paths. Methods like updateForMethodCall, removeConflicting(FieldAccess, ...), removeConflicting(ArrayAccess, ...), and removeConflicting(LocalVariable) do not invalidate entries in iteratedCollectionElements, which could allow stale facts to leak across iterations or after side-effecting operations.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@framework/src/main/java/org/checkerframework/framework/flow/CFAbstractStore.java`
around lines 79 - 80, The map iteratedCollectionElements can retain stale facts
across mutations; update the mutation/invalidation paths to evict affected
entries by clearing or removing matching keys from iteratedCollectionElements:
in updateForMethodCall(...) and the removeConflicting(...) overloads
(removeConflicting(FieldAccess,...), removeConflicting(ArrayAccess,...),
removeConflicting(LocalVariable,...)) identify which IteratedCollectionElement
keys reference the mutated target and remove them (or clear the whole map when a
conservative global mutation occurs) so iteratedCollectionElements cannot leak
outdated facts after side-effecting operations.

---

841-848: ⚠️ Potential issue | 🟡 Minor

Loose OR matching logic should require both node and tree to match.

The condition on line 843 uses OR logic across four comparisons, returning the first IteratedCollectionElement where any condition is true. Since IteratedCollectionElement.equals() requires both tree and node to match, the lookup should also enforce both requirements to avoid returning incorrect entries.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@framework/src/main/java/org/checkerframework/framework/flow/CFAbstractStore.java`
around lines 841 - 848, The lookup in getIteratedCollectionElement currently
returns an IteratedCollectionElement if any of four comparisons match; change
the logic to require both node and tree to match (mirroring
IteratedCollectionElement.equals). In method getIteratedCollectionElement,
iterate iteratedCollectionElements.keySet() and replace the compound condition
(ice.tree == tree || ice.node == node || ice.tree.equals(tree) ||
ice.node.equals(node)) with a check that both components match (e.g., (ice.tree
== tree || (ice.tree != null && ice.tree.equals(tree))) && (ice.node == node ||
(ice.node != null && ice.node.equals(node)))), then return ice only when both
match.

checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnalysis.java (1)

41-41: ⚠️ Potential issue | 🟡 Minor

Minor Javadoc formatting issue.

Line 41: missing space between "exact" and "{@link Throwable}".

Proposed fix

-   * <p>The policy follows the Resource Leak Checker configuration, but keeps exact{`@link` Throwable}
+   * <p>The policy follows the Resource Leak Checker configuration, but keeps exact {`@link` Throwable}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnalysis.java`
at line 41, In the Javadoc for class CollectionOwnershipAnalysis update the
comment that currently reads "exact{`@link` Throwable}" to insert a space so it
becomes "exact {`@link` Throwable}"; locate the Javadoc in
CollectionOwnershipAnalysis.java and adjust the spacing between "exact" and the
{`@link` Throwable} tag to fix the formatting.

checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipVisitor.java (1)

88-92: ⚠️ Potential issue | 🟠 Major

Fall back to declared receiver qualifier when flow store has no entry.

When getCoTypeAtTree returns null (no store entry), the method exits early without checking the declared type. This skips the @CreatesCollectionObligation enforcement for receivers whose ownership is only available from the declared type.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipVisitor.java`
around lines 88 - 92, When getCoTypeAtTree(receiverTree, storeBefore) returns
null, don't return immediately; instead obtain the declared/annotated receiver
type (via CollectionOwnershipAnnotatedTypeFactory.CollectionOwnershipType from
the annotated type factory using receiverTree or getAnnotatedType(receiverTree))
and assign it to receiverType so the subsequent `@CreatesCollectionObligation`
check runs even when the flow store lacks an entry; keep the existing null
guards and only return if both flow and declared lookups produce null.

checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnnotatedTypeFactory.java (5)

1023-1025: ⚠️ Potential issue | 🟠 Major

Don't compare Name instances with ==.

Different Name objects can have equal content, so this can miss the matching parameter slot and fail to propagate the declaration annotation to the use site.

Proposed fix

-            if (params.get(i).getSimpleName() == elt.getSimpleName()) {
+            if (params.get(i).getSimpleName().contentEquals(elt.getSimpleName())) {
               type.replaceAnnotation(paramTypes.get(i).getAnnotationInHierarchy(TOP));
               break;
             }

Based on learnings: In MustCallVisitor.java (Checker Framework), prefer using Name.equals(...) or Objects.equals(...) for com.sun.source.util.Name comparisons (instead of ==/!=). This should be the default unless the Interning Checker is explicitly used to guarantee reference equality.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnnotatedTypeFactory.java`
around lines 1023 - 1025, The code in CollectionOwnershipAnnotatedTypeFactory
compares Name objects using == (params.get(i).getSimpleName() ==
elt.getSimpleName()), which can miss matches; change the comparison to use
equals (e.g., params.get(i).getSimpleName().equals(elt.getSimpleName()) or
Objects.equals(...)) so the correct parameter slot from paramTypes is located
and the declaration annotation is propagated via
type.replaceAnnotation(paramTypes.get(i).getAnnotationInHierarchy(TOP)).

---

691-693: ⚠️ Potential issue | 🔴 Critical

Guard getAnnotatedType(tree) here and return null on unsupported trees.

This helper is called from the resource-leak analysis on arbitrary receiver trees. Without the same BugInCF guard used by isResourceCollection(Tree), unsupported tree shapes still crash analysis instead of yielding “no obligations”.

Based on learnings: In MustCallConsistencyAnalyzer.addObligationsForOwningCollectionReturn, treat a null result from CollectionOwnershipAnnotatedTypeFactory.getMustCallValuesOfResourceCollectionComponent(...) as “no obligations” and skip creating CollectionObligation(s); do not throw. This can occur for OwningCollection over non-resource element types.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnnotatedTypeFactory.java`
around lines 691 - 693, Guard the call to mcAtf.getAnnotatedType(tree) inside
CollectionOwnershipAnnotatedTypeFactory.getMustCallValuesOfResourceCollectionComponent
by catching the same BugInCF/unsupported-tree condition used in
isResourceCollection(Tree) and return null when the tree shape is unsupported;
update getMustCallValuesOfResourceCollectionComponent to return null instead of
letting the exception bubble. Then update
MustCallConsistencyAnalyzer.addObligationsForOwningCollectionReturn to treat a
null return from
CollectionOwnershipAnnotatedTypeFactory.getMustCallValuesOfResourceCollectionComponent(...)
as “no obligations” (i.e., skip creating CollectionObligation instances for
OwningCollection element types when the annotated type cannot be determined) so
analysis does not crash on non-resource element types.

---

488-516: ⚠️ Potential issue | 🟡 Minor

Mirror the null guard from isOwningCollectionField(...).

isResourceCollectionField(...) and isOwningCollectionParameter(...) both dereference elt immediately. Callers already pass nullable elements elsewhere in this PR, so these helpers should return false instead of NPEing.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnnotatedTypeFactory.java`
around lines 488 - 516, Both isResourceCollectionField(Element elt) and
isOwningCollectionParameter(Element elt) assume elt is non-null and can NPE;
mirror the null guard used elsewhere by adding an initial null check in each
method (e.g., if (elt == null) return false;) before any elt dereferences. This
ensures calls to isResourceCollectionField and isOwningCollectionParameter
(which call elt.getKind(), elt.asType(), getAnnotatedType(elt), etc.) safely
return false for null elements without changing downstream logic that uses
getAnnotatedType, getCoType, or compares to
CollectionOwnershipType.OwningCollection.

---

609-620: ⚠️ Potential issue | 🟠 Major

Use stub-aware ownership checks for inserted arguments.

Element.getAnnotation(...) ignores annotations supplied via stub files. A stubbed @Owning or @NotOwning declaration will be misclassified here, which breaks collection-obligation transfer soundness. Use rlAtf.hasOwning(...) / rlAtf.hasNotOwning(...) instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnnotatedTypeFactory.java`
around lines 609 - 620, The code in CollectionOwnershipAnnotatedTypeFactory uses
Element.getAnnotation(...) on insertedElement (from insertedArgumentTree) which
ignores stub-file annotations; replace those checks with the stub-aware queries
rlAtf.hasNotOwning(insertedElement) and rlAtf.hasOwning(insertedElement) so the
logic that returns CollectionMutatorArgumentKind.DEFINITELY_NON_OWNING or
MAY_BE_OWNING remains the same but respects stub declarations; update both the
initial NotOwning check and the parameter Owning check to call
rlAtf.hasNotOwning(...) / rlAtf.hasOwning(...) on insertedElement instead of
getAnnotation(...).

---

657-678: ⚠️ Potential issue | 🟠 Major

Map<K,V> still falls through as “no component obligations”.

ResourceLeakUtils.isCollection(...) treats Map as collection-like, but both overloads only extract a component when there is exactly one type argument. Resource obligations on map values are silently skipped.

Also applies to: 706-722

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/CollectionOwnershipAnnotatedTypeFactory.java`
around lines 657 - 678, getMustCallValuesOfResourceCollectionComponent currently
only extracts a single component type argument, so Map<K,V> (which has two type
arguments) falls through and value obligations are ignored; update the
extraction logic in getMustCallValuesOfResourceCollectionComponent to handle
both single-arg collection types and two-arg map-like types: if atm is an
AnnotatedDeclaredType with one type argument use that, and if it has two type
arguments (i.e., map-like) select the second argument as the component; then
pass that component to ResourceLeakUtils.getMcValues(componentType, mcAtf) as
before (refer to getMustCallValuesOfResourceCollectionComponent,
ResourceLeakUtils.isCollection, AnnotatedDeclaredType, and
ResourceLeakUtils.getMcValues).

checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java (8)

3547-3560: ⚠️ Potential issue | 🔴 Critical

A null back-edge summary must invalidate the whole loop proof.

If one back edge returns null, skipping the intersection preserves methods learned from other back edges and can still certify an unverified disposal loop.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 3547 - 3560, If any back-edge summary (calledMethodsAfterBlock
returned from analyzeTypeOfCollectionElement for the block within the loop) is
null, the entire loop proof must be invalidated instead of preserving prior
intersections; update the logic in the isLastBlockOfBody branch so that when
calledMethodsAfterBlock == null you set calledMethodsInLoop = null (and avoid
retaining previous values), using the existing variables calledMethodsInLoop,
calledMethodsAfterBlock, currentBlock, disposalLoop, obligations, and
loopUpdateBlock to locate the code and enforce that a single null summary clears
the accumulated calledMethodsInLoop.

---

2048-2053: ⚠️ Potential issue | 🟠 Major

Guard collection method-name lookup before calling .get(0).

Both diagnostics assume getMustCallValuesOfResourceCollectionComponent(...) returns a non-empty list. It can return null or an empty list, so these error paths can throw instead of reporting. Use the existing unknown-name fallback when no element method is available.

Based on learnings: When constructing diagnostics that reference an element method name, fall back to "Unknown" if the list is null/empty.

Also applies to: 2131-2135

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 2048 - 2053, The call to
coAtf.getMustCallValuesOfResourceCollectionComponent(...) in
MustCallConsistencyAnalyzer is assumed non-empty before calling .get(0), which
can cause NPEs or IndexOutOfBounds; update both places that call
checker.reportError(...) (the one using that list and the similar block around
the other reportError) to first check for null or empty and extract a safe
method-name (use the existing "Unknown" fallback used elsewhere) before passing
it into checker.reportError; i.e., compute a safeMethodName = list != null &&
!list.isEmpty() ? list.get(0) : "Unknown" (or reuse the module's fallback
helper) and use that value in the reportError invocation.

---

3713-3715: ⚠️ Potential issue | 🟠 Major

Handle store.getValue(ice) == null before calling getCalledMethods(...).

getCalledMethods dereferences its argument, so this path can NPE on bottom / no-live-element states instead of treating the back-edge summary as unavailable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 3713 - 3715, The code calls getCalledMethods(cmValOfIce) without
checking that store.getValue(ice) returned a non-null AccumulationValue; guard
against null by assigning AccumulationValue cmValOfIce = store.getValue(ice) and
then checking cmValOfIce != null before invoking getCalledMethods(cmValOfIce)
(or treat a null as "no summary" and skip the back-edge handling). Update the
branch that uses cmValOfIce/calledMethods (referenced symbols: store.getValue,
ice, cmValOfIce, getCalledMethods) to return/continue when cmValOfIce is null so
getCalledMethods is never called on null.

---

965-974: ⚠️ Potential issue | 🟠 Major

Don't consume the inserted value after checkEnclosingMethodIsCreatesMustCallFor(...) fails.

On the error path, the code still removes the caller-side obligation for the inserted element. That makes the analysis behave as if ownership transferred anyway, which can hide a later leak on the original value.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 965 - 974, The code currently always calls
consumeInsertedArgumentObligationIfSingleElementInsert(...), even when
checkEnclosingMethodIsCreatesMustCallFor(...) reports a failure; change the
control flow so the obligation is only consumed when the enclosing-method check
succeeds. Modify checkEnclosingMethodIsCreatesMustCallFor (or add a small
wrapper) to return a boolean success flag (e.g., true when no error reported) or
provide a way to detect failure, then call
consumeInsertedArgumentObligationIfSingleElementInsert(obligations, node) only
if that flag is true; update references in MustCallConsistencyAnalyzer around
receiverIsOwningField / receiverNode / enclosingMethodTree accordingly.

---

899-914: ⚠️ Potential issue | 🔴 Critical

Treat null component must-call values as “no obligations”.

getMustCallValuesOfResourceCollectionComponent(...) can legitimately return null for @OwningCollection over non-resource element types. Throwing BugInCF here turns a valid program into an analyzer crash.

Proposed fix

         List<String> mustCallValues =
             coAtf.getMustCallValuesOfResourceCollectionComponent(node.getTree());
-        if (mustCallValues == null) {
-          throw new BugInCF(
-              "List of MustCall values of component type is null for OwningCollection return value:"
-                  + " "
-                  + node);
-        }
-        if (!ResourceLeakUtils.isIterator(node.getType())) {
-          for (String mustCallMethod : mustCallValues) {
-            obligations.add(
-                new CollectionObligation(
-                    mustCallMethod, ImmutableSet.of(tmpVarAsResourceAlias), MethodExitKind.ALL));
-          }
+        if (mustCallValues == null || mustCallValues.isEmpty()
+            || ResourceLeakUtils.isIterator(node.getType())) {
+          return;
+        }
+        for (String mustCallMethod : mustCallValues) {
+          obligations.add(
+              new CollectionObligation(
+                  mustCallMethod, ImmutableSet.of(tmpVarAsResourceAlias), MethodExitKind.ALL));
         }

Based on learnings: In MustCallConsistencyAnalyzer.addObligationsForOwningCollectionReturn, treat a null result from CollectionOwnershipAnnotatedTypeFactory.getMustCallValuesOfResourceCollectionComponent(...) as “no obligations” and skip creating CollectionObligation(s); do not throw. This can occur for OwningCollection over non-resource element types.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 899 - 914, In addObligationsForOwningCollectionReturn, stop
throwing a BugInCF when
coAtf.getMustCallValuesOfResourceCollectionComponent(node.getTree()) returns
null; instead treat null as “no obligations” and skip creating
CollectionObligation(s) for that case. Locate the check that assigns
mustCallValues from getMustCallValuesOfResourceCollectionComponent, and if
mustCallValues is null simply return (or continue) without creating
ResourceAlias tmpVarAsResourceAlias or adding obligations to the obligations
set; preserve existing behavior for non-null mustCallValues. Ensure references
include addObligationsForOwningCollectionReturn, cmAtf.getTempVarForNode,
coAtf.getStoreAfter / getCoType, and
coAtf.getMustCallValuesOfResourceCollectionComponent.

---

536-607: ⚠️ Potential issue | 🟠 Major

CollectionObligation still breaks the equals/hashCode contract.

mustCallMethod participates in equals, but hashCode is inherited from Obligation, and the field is mutable even though Obligation is treated as deeply immutable. Distinct obligations can collide or be corrupted in hash-based collections.

Proposed fix

   /** The method that must be called on all elements of the collection. */
-  public String mustCallMethod;
+  public final String mustCallMethod;
@@
     `@Override`
     public boolean equals(`@Nullable` Object obj) {
@@
       return super.equals(obj) && collectionObligation.mustCallMethod.equals(this.mustCallMethod);
     }
+
+    `@Override`
+    public int hashCode() {
+      return Objects.hash(super.hashCode(), mustCallMethod);
+    }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 536 - 607, CollectionObligation breaks equals/hashCode because
mustCallMethod is mutable and not included in hashCode; make mustCallMethod
final (change declaration to final and update constructors to set it) and
override hashCode in CollectionObligation to combine super.hashCode() with
mustCallMethod.hashCode() (e.g., 31*super.hashCode()+mustCallMethod.hashCode())
so equals and hashCode remain consistent for CollectionObligation instances;
keep getReplacement() behavior as-is.

---

2100-2105: ⚠️ Potential issue | 🔴 Critical

OwningCollectionBottom is the nullable-field case, not a BugInCF.

This branch is reached when the field currently holds null. Overwriting null with a new owning collection should be treated as a safe assignment instead of aborting analysis.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 2100 - 2105, In MustCallConsistencyAnalyzer, the branch that checks
"lhsCoType == CollectionOwnershipType.OwningCollectionBottom" should not throw a
BugInCF because OwningCollectionBottom represents a nullable field being
overwritten; replace the throw with code that treats this as a safe assignment
(e.g., a no-op or appropriate continuation of analysis) and update the comment
to note that OwningCollectionBottom means the field may be null and can be
safely assigned; refer to the lhsCoType check in MustCallConsistencyAnalyzer and
remove the BugInCF construction for this case.

---

933-974: ⚠️ Potential issue | 🟠 Major

Model @CreatesCollectionObligation only on the normal edge, and enforce it on all later exits.

This helper is executed per successor edge, so it currently creates obligations on exceptional successors too, and CollectionObligation.fromTree(...) leaves whenToEnforce at NORMAL_RETURN. That can fabricate obligations in catch paths and under-enforce them after a successful insert.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/resourceleak/MustCallConsistencyAnalyzer.java`
around lines 933 - 974, The code currently creates collection obligations on
every successor edge; change addObligationsForCreatesCollectionObligationAnno so
it only creates obligations on the normal-successor (i.e., guard early with a
check for the normal/ordinary flow edge for the MethodInvocationNode) and when
constructing the obligation use the variant of CollectionObligation that sets
enforcement to "later exits" (or pass the appropriate whenToEnforce value
instead of leaving it at NORMAL_RETURN) so the obligation is enforced on all
subsequent exits; update the CollectionObligation.fromTree call to the
constructor/factory that accepts the whenToEnforce flag (or set the flag after
creation) and only call it when the node is on the normal path.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

checker/src/main/java/org/checkerframework/checker/collectionownership/WhileDisposalLoopMatcher.java (1)

655-660: ⚠️ Potential issue | 🟡 Minor

Use value equality for Name comparisons.

Line 658, Line 659, and Line 748 compare Name objects with ==, which can mis-match equivalent names and break loop matching/invalid-write detection.

Proposed fix

           private void markWriteIfTargetsHeaderOrCollection(ExpressionTree lhs) {
             Name assigned = CollectionOwnershipUtils.getNameFromExpressionTree(lhs);
             if (assigned != null) {
-              if (assigned == headerVar) illegal.set(true);
-              if (collectionVarName != null && assigned == collectionVarName) illegal.set(true);
+              if (assigned.equals(headerVar)) illegal.set(true);
+              if (collectionVarName != null && assigned.equals(collectionVarName)) illegal.set(true);
             }
           }
@@
     Name recv = CollectionOwnershipUtils.getNameFromExpressionTree(ms.getExpression());
-    return recv != null && recv == headerVar;
+    return recv != null && recv.equals(headerVar);
   }

#!/bin/bash
# Verify there are no remaining reference-equality checks on Name for these comparisons.
rg -n --type=java -C2 '\b(assigned|recv)\s*==\s*(headerVar|collectionVarName)\b' \
  checker/src/main/java/org/checkerframework/checker/collectionownership/WhileDisposalLoopMatcher.java
# Expected: no matches

Based on learnings: prefer using Name.equals(...) or Objects.equals(...) for Name comparisons instead of ==/!=.

Also applies to: 747-748

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/WhileDisposalLoopMatcher.java`
around lines 655 - 660, Replace reference-equality checks on Name with
value-equality: in WhileDisposalLoopMatcher (method
markWriteIfTargetsHeaderOrCollection) change comparisons like assigned ==
headerVar and assigned == collectionVarName to use Name.equals(...) or
Objects.equals(assigned, headerVar) / Objects.equals(assigned,
collectionVarName); likewise update the recv == headerVar / recv ==
collectionVarName checks around the recv handling (lines referenced near
747-748) to use equals/Objects.equals so equivalent Name instances compare
correctly.

checker/src/main/java/org/checkerframework/checker/collectionownership/IndexedForDisposalLoopMatcher.java (2)

64-65: ⚠️ Potential issue | 🟠 Major

Still guard the loop condition before stripping parens.

ForLoopTree.getCondition() can be null, so TreeUtils.withoutParens(...) will still throw on for (;;) before the matcher can reject the loop.

Suggested fix

-    ExpressionTree condition = TreeUtils.withoutParens(tree.getCondition());
+    ExpressionTree rawCondition = tree.getCondition();
+    if (rawCondition == null) {
+      return null;
+    }
+    ExpressionTree condition = TreeUtils.withoutParens(rawCondition);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/IndexedForDisposalLoopMatcher.java`
around lines 64 - 65, The code calls
TreeUtils.withoutParens(tree.getCondition()) without guarding against
tree.getCondition() being null, which will throw for an empty-condition
for-loop; modify the logic in IndexedForDisposalLoopMatcher (the method handling
the ForLoopTree) to first check tree.getCondition() != null (and only then call
TreeUtils.withoutParens), returning/rejecting the loop early if the condition is
null so the matcher doesn't throw.

---

181-226: ⚠️ Potential issue | 🟠 Major

Skip nested scopes in the body scan.

This scanner still descends into lambdas and local/anonymous classes, so a write or collection.get(i) inside an unrelated nested scope can incorrectly certify or invalidate the outer loop.

Suggested fix

 import com.sun.source.tree.AssignmentTree;
 import com.sun.source.tree.BinaryTree;
 import com.sun.source.tree.CompoundAssignmentTree;
+import com.sun.source.tree.ClassTree;
 import com.sun.source.tree.ExpressionStatementTree;
 import com.sun.source.tree.ExpressionTree;
 import com.sun.source.tree.ForLoopTree;
 import com.sun.source.tree.IdentifierTree;
 import com.sun.source.tree.LiteralTree;
+import com.sun.source.tree.LambdaExpressionTree;
 import com.sun.source.tree.MemberSelectTree;
 import com.sun.source.tree.MethodInvocationTree;
+import com.sun.source.tree.NewClassTree;
 import com.sun.source.tree.StatementTree;
 import com.sun.source.tree.Tree;
 import com.sun.source.tree.UnaryTree;
 import com.sun.source.tree.VariableTree;
@@
         new TreeScanner<Void, Void>() {
+          `@Override`
+          public Void visitLambdaExpression(LambdaExpressionTree tree, Void p) {
+            return null;
+          }
+
+          `@Override`
+          public Void visitClass(ClassTree tree, Void p) {
+            return null;
+          }
+
+          `@Override`
+          public Void visitNewClass(NewClassTree tree, Void p) {
+            return null;
+          }
+
           `@Override`
           public Void visitUnary(UnaryTree tree, Void p) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@checker/src/main/java/org/checkerframework/checker/collectionownership/IndexedForDisposalLoopMatcher.java`
around lines 181 - 226, The TreeScanner currently descends into nested scopes
(lambdas and local/anonymous classes) and thus can see writes or
collection.get(i) in unrelated scopes; fix by overriding the scope-entry visit
methods on the anonymous TreeScanner (the scanner variable in
IndexedForDisposalLoopMatcher) to stop traversal into nested scopes — add
overrides for visitLambdaExpression(LambdaExpressionTree),
visitNewClass(NewClassTree) and visitClass(ClassTree) that simply return null
(do not call super) so the scanner skips descending into those nested scopes.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes